Многие администраторы часто добавляют новые хосты ESXi, но довольно редко обсуждается вопрос о том, как правильно выводить из эксплуатации хост VMware ESXi. Об этом интересную статью написал Stephen Wagner.

Многих может удивить, что нельзя просто выключить хост ESXi и удалить его из окружения сервера vCenter, так как необходимо выполнить ряд шагов заранее, чтобы обеспечить успешный вывод из эксплуатации (decomission). Правильное списание хоста ESXi предотвращает появление изолированных объектов в базе данных vCenter, которые иногда могут вызывать проблемы в будущем.

Итак, процесс: как списать хост ESXi

Предполагается, что вы уже перенесли все ваши виртуальные машины, шаблоны и файлы с хоста, и он не содержит данных, которые требуют резервного копирования или миграции. Если вы этого не сделали - проверьте все еще раз, на хосте могут оказаться, например, кастомные скрипты, которые вы не сохраняли в другом месте.

Вкратце процесс выглядит так:

• Перевод ESXi в режим обслуживания (Maintenance Mode)
• Удаление хоста из распределенного коммутатора vSphere Distributed Switch (vDS)
• Отключение и размонтирование томов iSCSI LUN
• Перемещение хоста из кластера в датацентр как отдельного хоста
• Удаление хоста из инвентаря (Inventory)
• Выполнение расширенных процедур

Вход в режим обслуживания

Мы переходим в режим обслуживания, чтобы убедиться, что на хосте не запущены виртуальные машины. Вы можете просто щелкнуть правой кнопкой мыши по хосту и войти в режим обслуживания (Enter Maintenance Mode):

Если хост ESXi входит в состав кластера VMware vSAN, то вам будут предложены опции того, что нужно сделать с данными на нем хранящимися:

Удаление хоста из окружения vSphere Distributed Switch (vDS)

Необходимо аккуратно удалить хост из любых распределенных коммутаторов vDS (VMware Distributed Switches) перед удалением хоста из сервера vCenter.

Вы можете создать стандартный vSwitch и мигрировать адаптеры vmk (VMware Kernel) с vDS на обычный vSwitch, чтобы поддерживать связь с сервером vCenter и другими сетями.

Обратите внимание, что если вы используете коммутаторы vDS для подключений iSCSI, необходимо заранее разработать план по этому поводу, либо размонтировать/отключить iSCSI LUN на vDS перед удалением хоста, либо аккуратно мигрировать адаптеры vmk на стандартный vSwitch, используя MPIO для предотвращения потери связи во время выполнения процесса.

Размонтирование и отключение iSCSI LUN

Теперь вы можете приступить к размонтированию и отключению iSCSI LUN с выбранного хоста ESXi:

• Размонтируйте тома iSCSI LUN с хоста
• Отключите эти iSCSI LUN

Нужно размонтировать LUN только на выводимом из эксплуатации хосте, а затем отключить LUN также только на списываемом хосте.

Перемещение хоста из кластера в датацентр как отдельного хоста

Хотя это может быть необязательным, это полезно, чтобы позволить службам кластера vSphere (HA/DRS) адаптироваться к удалению хоста, а также обработать реконфигурацию агента HA на хосте ESXi. Для этого вы можете просто переместить хост из кластера на уровень родительского дата-центра.

Удаление хоста из инвентаря

После перемещения хоста и прошествия некоторого времени, вы теперь можете приступить к его удалению из Inventory. Пока хост включен и все еще подключен к vCenter, щелкните правой кнопкой мыши по хосту и выберите «Remove from Inventory». Это позволит аккуратно удалить объекты из vCenter, а также удалить агент HA с хоста ESXi.

Повторное использование хоста

Начиная с этого момента, вы можете войти напрямую на хост ESXi с помощью локального пароля root и выключить хост. Сделать этого можно также с помощью обновленного VMware Host Client.

Дункан Эппинг опубликовал интересный пост о том, как предотвратить исполнение виртуальных машин vCLS на VMware vSphere HA Failover Host. Напомним, что vSphere Clustering Service (vCLS) - это служба, которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Она реализуется тремя агентскими виртуальными машинами в кластере, где 3 или более хостов, и двумя, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.

Для тех, кто не знает, сервер vSphere HA Failover Host — это хост, который используется, когда происходит сбой и vSphere HA должен перезапустить виртуальные машины. В некоторых случаях клиенты (обычно партнеры в облачных решениях) хотят предотвратить использование этих хостов для любых рабочих нагрузок, поскольку это может повлиять на стоимость использования платформы.

К сожалению, в пользовательском интерфейсе вы не можете указать, что машины vCLS не могут работать на определенных хостах, вы можете ограничить работу ВМ vCLS рядом с другими виртуальными машинами, но не хостами. Однако есть возможность указать, на каких хранилищах данных могут находиться виртуальные машины, и это может быть потенциальным способом ограничения хостов, на которых могут работать эти ВМ. Как?

Если вы создадите хранилище данных, которое недоступно назначенному Failover-хосту vSphere HA, то машины vCLS не смогут работать на этом хосте, так как хост не сможет получить доступ к датастору. Это обходной путь для решения проблемы, вы можете узнать больше о механизме размещения хранилищ данных для vCLS в этом документе. Обратите внимание, что если остальная часть кластера выйдет из строя и останется только Failover-хост, виртуальные машины vCLS не будут включены. Это означает, что механизм балансировки нагрузки VMware DRS также не будет функционировать, пока эти ВМ недоступны.

На днях VMware от Broadcom представила бета-версию нового издания продукта для управления отдельными хостами ESXi - VMware Host Client. Все пользователи, зарегистрированные в программе бета-тестирования vSphere, могут получить доступ к новой бета-версии Host Client и загрузить обновленный графический интерфейс для работы с серверами ESXi.

Устаревший VMware Host Client сталкивался с технологическими трудностями и проблемами удобства использования, поэтому был переведен в режим поддержки без значимых обновлений. Для устаревшего клиента решались только критические проблемы, связанные с безопасностью или доступностью графического интерфейса. VMware уже давно обещала выпустить новое издание Host Client - и вот теперь оно доступно, но в рамках бета-программы.

Поскольку это первая версия нового пользовательского интерфейса для управления ESXi, она охватывает только базовые процессы управления самим хостом и виртуальными машинами и лишь некоторые операции. VMware будет постепенно расширять функциональность самыми важными рабочими операциями, чтобы предоставить пользователям vSphere мощный инструмент для управления хостом, охватывающий критические сценарии устранения неполадок на уровне ESXi (а также в случае недоступности vCenter).

Бета-версия нового Host Client — это веб-приложение, которое может быть использовано в macOS, Windows или Linux. Оно не связано с конкретной версией ESXi и, таким образом, может подключаться как к самым последним версиям гипервизора, так и к более старым. При подключении к ESXi можно сохранить данные подключения, чтобы обеспечить легкое переключение между серверами.

Внешний вид нового графического пользовательского интерфейса аналогичен пользовательскому опыту клиента vSphere. Представления данных поддерживают как список, так и вид карточек, а также имеют быструю фильтрацию по строкам:

В качестве отправной точки бета-версия охватывает следующий набор функций:

• Просмотр общей информации о ESXi – емкость ресурсов, оборудование, конфигурация, история производительности.
• Просмотр списка виртуальных машин, расположенных на хосте ESXi.
• Управление виртуальной машиной – операции c питанием, снапшоты, изменение настроек ВМ и открытие ее консоли.
• Просмотр алармов, событий и предупреждений, связанных с хостом ESXi.
• Живой мониторинг задач, связанных с хостом ESXi.
• Управление хранилищем – просмотр деталей и увеличение емкости.

В рамках бета-версии пользователям предоставляется возможность принять участие в программе улучшения пользовательского опыта, позволяя команде VMware собирать телеметрию. Вы также можете поделиться отзывом, используя специальную форму, доступную из консоли Host Client.

Имейте в виду, что устаревший Host Client входит в состояние снятия с производства. Он все еще будет доступен и поддерживаться в общедоступной версии следующего крупного выпуска vSphere и будет сосуществовать с новым пользовательским интерфейсом ESXi. Однако в ходе обновлений следующего мажорного релиза поддержка устаревшего Host Client будет прекращена, и он не будет доступен версии +1.

Скачать бета-версию нового VMware Host Client можно по этой ссылке, заполнив там соответствующую форму.

Сотрудники компании VMware выпустили постеры о VMware Cloud Foundation. В ответ на запрос пользователей, постеры выполнены в темном и светлом форматах. Каждый постер демонстрирует возможности платформы создания частного облака VMware Cloud Foundation 5 на базе гипервизора VMware vSphere.

Вы можете бесплатно скачать постеры тут, распечатать их и повесить в серверной своего датацентра.

Начиная с верхнего левого угла, представлены два актора: Cloud Admin и Developer. Каждый из них со своими компьютерами, подключенными к физической сети VLAN с многоцветной маркировкой, что позволяет им подключаться и управлять датацентром Software Defined Data Center (SDDC).

Наблюдая за стойками физической инфраструктуры, мы можем видеть стойки серверов, составляющие Management Domain и Workload Domains, а также то, как они соотносятся с логическим представлением SDDC Workload Domains на остальной части постера ниже. Из коммутаторов верхнего уровня стойки (top of rack, TOR) мы видим физические VLAN и то, как они подключаются к нескольким физическим сетевым интерфейсам (vmnics) внутри хостов ESXi, и как они сопоставляются с аплинками и распределенными коммутаторами внутри VCF. Также обратите внимание на маленькие белые облака BGP, они указывают на то, как Edge-устройства NSX в каждом домене нагрузки подключаются к вышестоящему физическому сетевому слою BGP-пира.

Переходя к управляющему домену, мы видим цветную легенду всех VLAN, используемых для настройки VCF Software Defined Data Center, вместе со всеми управляющими виртуальными машинами, которые составляют эту инсталляцию VCF.

Нововведение этого постера - теперь мы видим проект NSX с модулями NSX VPC, предоставляющий программно-определенную сеть для прикладных виртуальных машин.

Раздел Workload Domain 2 раскрывает архитектуру для запущенных кластеров Tanzu Kubernetes внутри VCF.

Для удаленных сайтов мы видим, что VCF также поддерживает архитектуры удаленных кластеров:

Ну и в целом, в постере есть много полезной информации для понимания архитектуры VMware Cloud Foundation. Скачивайте.

В связи с тем, что бесплатный сервер виртуализации VMware ESXi Free больше недоступен (он же vSphere Hypervisor), многие начинающие пользователи задумались о том, как получить платформу VMware vSphere для ознакомления и тестирования, не покупая сам продукт сразу.

Для многих продуктов VMware (в том числе vSphere) есть бесплатная пробная лицензия на 60 дней, которую вы можете получить самостоятельно. Тут есть 2 ограничения:

• Если вы и ваша компания находитесь в России или Беларуси, то легально получить такую лицензию не получится.
• Не все продукты VMware имеют пробные версии на 60 дней, некоторые решения нужно запрашивать через партнеров или в отделе продаж VMware (как правило, это специфические Enterprise-решения).

Итак, рассмотрим этот процесс на примере VMware vSphere. Идем по этой ссылке:

https://www.vmware.com/try-vmware.html

В поиске вбиваем интересующий нас продукт, например, vSphere. Там будет несколько результатов (например, лабораторные работы), находим нужный нам Trial и кликаем по ссылке.

Если у вас уже есть аккаунт VMware Connect, то вы можете зайти под ним в разделе справа. Если же нет, то его можно создать (Create an Account):

Если вы уже использовали пробную версию vSphere на 60 дней в прошлом, то второй раз попробовать продукт уже не получится. Если же вы делаете это впервые, то у вас будет кнопка Register, которая позволит вам зарегистрироваться в программе пробного использования:

Далее нужно будет заполнить анкету, где указывается информация о вас и вашей организации:

После этого в разделе License&Download вам будет доступна лицензия на полнофункциональную версию vSphere Cloud Foundation (VCF) на 60 дней, а также ссылки на скачивание компонентов VMware vSphere.

Также вы можете скачать VMware vSphere и ее компоненты в любой момент по следующей ссылке (для этого не нужно регистрироваться в программе пробного периода):

https://customerconnect.vmware.com/en/downloads/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/8_0

Интересно, много ли у нас читателей, кто помнит, что такое операционная система (а точнее, ее половинка) Microsoft OS/2? Недавно известный блоггер Вильям Лам выпустил ностальгический пост об установке OS/2 в виртуальной машине на платформе VMware ESXi.

Один софтверный археолог (да-да, software archaeologist) под ником Neozeed сделал видео об установке предрелизной версии OS/2 2.0, созданной совместно Microsoft и IBM под руководством последней (такое тоже было). Развертывание старинной операционной системы было сделано с помощью бесплатного продукта Workstation Player:

Техспот недавно писал о том, что были обнаружены пакеты OS/2 Warp, подготовленные для виртуальных машин.

Поэтому Вильям взял установочные образы OS/2 от Neozeed и без проблем развернул их в виртуальной машине на ESXi 8.0 Update 2b. И все заработало! Кстати, в оригинальной статье Вильяма много интересных ностальгических каментов.

Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.

Компания VMware провела тестирование работы баз данных Oracle в среде vSAN ESA и опубликовала некоторые результаты.

Тестовый стенд

Тестовая площадка представляла собой кластер из 8 узлов vSAN 8 Express Storage Architecture (ESA) со следующими настройками:

• Версия vCenter 8.0.2 сборка 22385739
• 8 серверов Lenovo ThinkAgile VX7531 Node, 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU @ 2.60GHz, 1TB RAM
• VMware ESXi 8.0.2, сборка 22380479 с vSAN ESA (все хранилища - NVMe)
• Oracle 21.13 Grid Infrastructure, ASM Storage и Linux udev (размер блока базы данных 8k)
• OEL UEK 8.9

Детали кластера vSAN Express Storage Architecture (ESA) "env175" показаны ниже. Кластер ESA состоит из 8 серверов Lenovo ThinkAgile VX7531, как показано на картинке:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU на частоте 2.60GHz и 1TB RAM:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 6 внутренних накопителей NVMe, таким образом каждый сервер дает 6 внутренних устройств NVMe в качестве емкости датастора vSAN ESA:

Информация о сервере ThinkAgile VX7531 "env175-node1.pse.lab" в части деталей HBA и внутренних устройств NVMe:

Политики хранения кластера vSAN Express Storage Architecture (ESA) показаны на картинке ниже.

Базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана только для получения эталонных метрик для сравнения, кроме того, настоящая производственная нагрузка никогда не настраивается с FTT=0 (количество допустимых отказов) и без RAID (то есть без защиты).

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

Детали виртуальной машины "Oracle21C-OL8-DB_ESA" показаны на картинке ниже.

Виртуальная машина имеет 28 vCPU, 256 ГБ RAM. Один экземпляр базы данных "ORA21C" был создан с опцией multi-tenant на базе инфраструктуры Oracle Grid (ASM). Версия базы данных - 21.13 на операционной системе OEL UEK 8.9.

Oracle ASM использовалась как платформа хранения данных с Linux udev для обеспечения персистентности устройств. Oracle SGA и PGA были установлены на 64G и 10G соответственно. Также были соблюдены все лучшие практики платформы Oracle на VMware.

Виртуальная машина "Oracle21C-OL8-DB_ESA" имеет 4 контроллера vNVMe для дополнительной производительности:

58 устройств хранения привязаны к ВМ "Oracle21C-OL8-DB_ESA", они показаны ниже:

• NVME 0:0 – 80G для OS (/)
• NVME 0:1 – 80G для Oracle Grid и бинарников RDBMS
• NVME 0:2 – 100G для GRID_DG
• NVME 0:3 – 200G для DATA_DG
• NVME 0:4 – 200G для DATA_DG
• NVME 0:5 – NVME 0:12 – 8 дисков vmdk, каждый 25 ГБ – REDO_DG
• NVME 1:0 – 1:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 2:0 – 2:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 3:0 – 3:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG

Детали тестов разных политик хранения vmdk для ВМ "Oracle21C-OL8-Customer" показаны ниже:

• Тест 1 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT0 – NoRAID"
• Тест 2 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT1 – R5"
• Тест 3 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT2 – R6"

Детали группы дисков Oracle ASM показаны ниже:

Тестовый сценарий

Результаты ниже являются тестовым сценарием, демонстрирующим преимущества производительности использования vSAN 8 vSAN Express Storage Architecture (ESA) для бизнес-критичных производственных нагрузок Oracle.

Генератор нагрузки SLOB был запущен против 2 TB табличного пространства SLOB с 3 различными политиками хранения.

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

В качестве генератора нагрузки для этого эксперимента был выбран SLOB 2.5.4.0 с следующими установленными параметрами SLOB:

UPDATE_PCT=30
RUN_TIME=300
SCALE=25G
WORK_UNIT=1024

Для имитации модели нагрузки с многосхемной работой использовались несколько схем SLOB, и количество потоков на схему было установлено в 20.

Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.

В VMware провели несколько прогонов SLOB для вышеупомянутого кейса и сравнили метрики Oracle, как показано в таблице ниже.

Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.

Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.

Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.

Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:

• Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
• Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
• Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов

Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":

В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Как знают многие администраторы платформы vSphere, после покупки компании VMware гигантом Broadcom было официально решено изменить продуктовую линейку vSphere на модель лицензирования по подписке и оставить два Enterprise-издания - VMware vSphere Foundation (VVF - решение для онпремизных сред) и VMware Cloud Foundation (VCF - облачная платформа на базе различных сервис-провайдеров). Мы это также объясняли в картинках, на которых видно, что большинство продуктов теперь доступны как аддоны к указанным выше изданиям. Также остались и решения для небольших организаций - это VMware vSphere Essentials Plus Kit (VVEP) и VMware vSphere Standard (VVS).

Многие пользователи уже привыкли, что бесплатный гипервизор VMware ESXi Free (он официально назывался vSphere Hypervisor) доступен для скачивания с сайта VMware, но вот уже месяц назад это стало недоступно. Причина проста - бесплатного издания больше нет, виртуализация от VMware теперь поставляется только за деньги.

Официальное оповещение пользователей об этом находится в KB 2107518 от 14 февраля этого года - End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x).

Не то, чтобы это было сделано как-то втихую, но особо нигде и не обсуждалось - ну убрали и убрали. На самом деле, решение это, на наш взгляд, неверное - множество администраторов начинали именно с бесплатного издания, учились на нем азам виртуализации и операциям с виртуальными машинами, делали тестовые лаборатории, создавали кластеры высокой доступности и балансировки нагрузки (на пробных версиях vSphere или ломаных). Теперь же ничего этого нет - чтобы начать эксплуатацию платформы VMware vSphere надо заплатить после пробного периода, но далеко не все могут себе это позволить.

Кстати, видно, что энтузиасты, эксперты и блоггеры также не очень довольны этим фактом, поэтому, возможно, Broadcom еще вернется к вариантам бесплатной виртуализации для целей обучения и совсем малых инсталляций. Не зря же в статье базы знаний написано "at this time", поэтому посмотрим...

На днях компания VMware выпустила обновления для своей флагманской платформы VMware vSphere 8 Update 2 - ESXi 8.0 Update 2b и vCenter 8.0 Update 2b.

Что нового появилось VMware ESXi 8.0 Update 2b:

• 100 GiB пробной емкости хранения на каждое ядро vSAN - начиная с vSphere 8.0 Update 2b, в рамках предложения VMware vSphere Foundation, вы можете использовать до 100 гибибайт (GiB) хранилища vSAN на каждое лицензированное ядро хоста vSAN без применения лицензионного ключа vSAN. Для емкости, превышающей 100 GiB на каждое ядро vSAN, вы можете приобрести емкость vSAN на тебибайт (TiB) и применить ключ vSAN, отражающий общую сырую емкость хранилища кластера vSAN. Для получения дополнительной информации о отчетах по емкости и лицензировании vSAN смотрите "Разъяснение отчетности по емкости в vSAN" и "Подсчет ядер для VMware Cloud Foundation и vSphere Foundation и TiB для vSAN".
• Добавлена поддержка технологии vSphere Quick Boot для множества серверов: 
  • Dell - MX760c vSAN Ready Node, PowerEdge C6615, PowerEdge XR8610t, R7625 vSAN Ready Node, VxRail VP-760xa, VxRail VS-760
  • HPE - Alletra Storage Server 4110/4140, Cray XD670, ProLiant DL110 Gen11/DL20 Gen11/ProLiant ML30 Gen11
  • Lenovo DN8848 V2
• Исправлена ошибка с необнаружением Apple NVMe на Apple Mac Mini 2018. Об этом написал Вильям Лам.

Более подробно об обновлении VMware ESXi 8.0 Update 2b написано в Release Notes.

Что нового появилось VMware vCenter Server 8.0 Update 2b:

• Агрегация статистики по GPU на уровне хоста и кластера - в этом обновлении vCenter вы можете отслеживать агрегацию метрик GPU на уровне хоста и кластера, что полезно для нагрузок генеративного искусственного интеллекта, традиционных нагрузок AI и других, ускоренных с помощью GPU. В клиенте vSphere, в разделе Monitor > Performance, вы увидите:
  • на уровне хоста: обзорные диаграммы производительности и расширенные диаграммы производительности для использования вычислений на GPU, распределения памяти и температуры на хостах.
  • на уровне кластера: расширенные диаграммы производительности с агрегированной статистикой от хостов для памяти GPU и использования GPU.
• Для получения дополнительной информации смотрите "Работа с расширенными и пользовательскими диаграммами" и "Обзорные диаграммы производительности".
• Обновления vSphere with Tanzu (подробности тут) и Photon OS (подробности здесь).

Более подробно об обновлении vCenter Server 8.0 Update 2b написано в Release Notes.

Скачать VMware vSphere 8 Update 2, включая ESXi 8.0 Update 2b и vCenter Server 8.0 Update 2b можно по этой ссылке.

Пару лет назад мы писали о производительности Microsoft SQL Server в облаке VMware Cloud on AWS для инстанса AWS-i4i.metal. С тех пор много что изменилось, а компания VMware анонсировала новый тип экземпляра m7i для VMware Cloud на AWS, который использует сетевое хранилище NFS вместо vSAN. Это предоставляет клиентам гибкое и масштабируемое хранилище на основе VMware Cloud Flex Storage и Amazon FSx для NetApp ONTAP.

Для других типов экземпляров VMware Cloud на AWS включено хранилище vSAN, которое базируется на локальных дисках каждого хоста. Хранилища данных vSAN растут вместе с кластером по мере добавления новых узлов. С m7i количество хранилища не зависит от числа хостов, и вы можете настроить его в зависимости от требований к хранилищу.

Ниже рассмотрим производительность виртуальных машин SQL Server, работающих на 3-узловом кластере m7i с хранилищем NFS, по сравнению с 3-узловым кластером i4i с хранилищем vSAN. Инстансы m7i основаны на процессорах Intel, которые на одно поколение новее, чем i4i. Вот чем отличаются эти инстансы:

Методология

Для тестов использовался набор ВМ с 16 vCPU и 24 vCPU. Поскольку экземпляры m7i имели 48 ядер, как 16 vCPU, так и 24 vCPU были равномерно распределены по общему количеству ядер, что облегчало сравнение производительности и делало его понятным. Для поддержки максимального числа ВМ с 16 vCPU на кластере m7i каждой ВМ назначили 60 ГБ ОЗУ.

Для тестов использовали ВМ Windows Server 2022 с установленным Microsoft SQL Server 2022 и применили открытый инструментарий бенчмаркинга DVD Store 3.5 для запуска нагрузок OLTP-приложений на SQL Server и измерения результатов. DVD Store симулирует онлайн-магазин, где клиенты просматривают, оставляют отзывы и оценивают, регистрируются и покупают продукты. Результаты выражаются в заказах в минуту (OPM), что является мерой пропускной способности. Чем выше показатели OPM - тем лучше.

Результаты производительности ВМ SQL Server с 24 vCPU против 16 vCPU

Результаты на рисунках 1 и 2 показывают производительность ВМ с 24 vCPU и 16 vCPU. Линия обозначает общую пропускную способность в OPM по всем ВМ в каждом тесте. Количество ВМ увеличивается в каждом тесте, начиная с 1 и заканчивая максимально возможным, исходя из количества vCPU, соответствующих числу доступных потоков в кластере.

Темп прироста OPM замедляется, когда количество vCPU превышает количество физических ядер и необходимо использовать второй логический поток (hyperthread) на каждом ядре. Это начинается с 8 и 12 ВМ для тестов с 24 и 16 vCPU соответственно.

Столбцы в каждом графике представляют использование CPU трех хостов для каждого теста. По мере добавления ВМ, VMware Distributed Resource Scheduler (DRS) автоматически размещал и, возможно, динамически перемещал ВМ между хостами для управления нагрузкой. Как показывают результаты, это поддерживало использование CPU на всех хостах довольно стабильным, даже когда нагрузка увеличивалась.

Последняя точка данных в тесте с 16 vCPU (рисунок 2) показывает небольшое снижение OPM, поскольку на этом этапе теста кластер немного перегружен. Несмотря на это, можно было продолжить масштабирование производительности кластера m7i, добавляя больше инстансов. В этих тестах был использован только кластер из 3 инстансов, но можно было бы добавить больше инстансов в кластер для увеличения его емкости.

Рисунок 1 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 24 vCPU на ВМ:

Рисунок 2 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 16 vCPU на ВМ:

Рисунок 3 сравнивает производительность ВМ с 16 vCPU и 24 vCPU таким образом, что в каждом тестовом случае назначалось одинаковое общее количество vCPU. Например, для 48 vCPU 2?24 vCPU сравниваются с 3?16 vCPU (по сумме - 48 в обоих случаях).

Рисунок 3 - производительность ВМ SQL Server: 16 vCPU по сравнению с 24 vCPU:

Сравнение производительности m7i с i4i

Те же ВМ были перенесены на кластер i4i и тесты повторили. Важно отметить, что чтобы сохранить ВМ максимально идентичными, им не увеличивали объем RAM, несмотря на то, что в кластере i4i было примерно в 2,5 раза больше RAM.

Как показывает рисунок 4, результаты для i4i были схожи в плане OPM и использования CPU хоста. Основное отличие: получилось запустить до 24 ВМ на i4i против максимума 18 ВМ на m7i. Это связано с большим количеством ядер и большей памятью в экземплярах i4i.

Рисунок 4 - трехузловой кластер i4i VMware Cloud on AWS: SQL Server ВМ и использование CPU хоста на ВМ с 16 vCPU по сравнению с vSAN:

Рисунок 5 показывает различия между m7i и i4i. Поскольку отдельные ядра экземпляров m7i имеют более высокую производительность, чем ядра кластера i4i, рисунок 5 показывает преимущество в производительности на левой стороне графика. Как только экземплярам m7i необходимо полагаться на второй логический поток (hyperthread) от каждого физического ядра для поддержки рабочих нагрузок, производительность i4i становится схожей. И, наконец, когда экземпляры i4i полностью используют преимущество большего количества ядер, их производительность превышает производительность m7i.

Рисунок 5 - различие между m7i и i4i:

Тестирование производительности говорит о хорошей работе SQL Server на m7i в рамках предоставляемой экземплярами m7i ресурсной емкости. Поскольку экземпляры m7i имеют меньше ядер и меньше памяти, чем i4i, важно использовать инструмент VMC Sizer, чтобы убедиться, что платформа соответствует потребностям баз данных.

Также наблюдались немного более высокие задержки с подключенным к m7i хранилищем NFS, но в целом это не оказало большого влияния на результаты тестов. Важно также правильно подобрать хранилище NFS, подключенное к m7i, и установить для хранилища IOPs и пропускную способность на уровни, соответствующие требованиям рабочей нагрузки.

Недавно компания VMware представила очередной релиз платформы виртуализации и доставки настольных ПК и приложений Horizon 8 2312, в котором появилось несколько функций, разработанных для улучшения опыта работы как администраторов, так и конечных пользователей. Horizon 2312 предлагает набор возможностей, направленных на оптимизацию операций, обеспечение безопасности сессий, повышение производительности и добавление большей персонализации к каждой сессии. Напомним, что о прошлой версии VMware Horizon 8 2306 мы рассказывали вот тут.

Horizon 2312 является последним релизом ветки Extended Service Branch (ESB) - это означает, что VMware предоставит несколько будущих обновлений, содержащих критические исправления ошибок и поддержку новых версий ОС в течение трехлетнего периода. Более подробно об этом рассказано здесь.

Давайте посмотрим, что нового в Horizon 2312:

Улучшения клиента и агента Horizon

Во-первых, давайте рассмотрим все улучшения, внесенные в Horizon Agent и Client, которые повышают производительность и персонализацию для конечного пользователя, а также оптимизируют безопасность и операции для ИТ.

1. Автоматическое обновление агента Horizon для упрощения обслуживания

Вы можете оптимизировать ваши Day-2 операции с помощью активной технологии виртуального рабочего стола (VDI), используя функцию auto-upgrade для агента Horizon, которая автоматизирует обновления по всем вашим VDI или RDSH десктопам, убирая необходимость в ручных обновлениях. Эта функция доступна эксклюзивно для клиентов с лицензией Horizon Plus или Horizon Universal и применима для рабочих столов Full Clone и серверов RDSH. Для обновления агента Horizon в пулах мгновенных клонов или фермах удаленных рабочих столов (RDS) просто обновите агент Horizon в золотом образе и запланируйте окно технического обслуживания для развертывания нового образа.

2. Оптимизированная производительность CPU

Протокол Blast продолжает повышать производительность удаленных рабочих столов за счет оптимизации операций с процессором. Регулируя частоту кадров, CPU умно управляет тем, когда и как применяется увеличенная вычислительная мощность, обеспечивая лучшую плотность ВМ и производительность. Это не только улучшает эффективность использования ресурсов, но и делает опыт конечных пользователей более комфортным.

3. Улучшенные изображения с бинарным lossless-режимом для кодека Blast

Horizon 2312 вводит бинарный lossless-режим для кодека Blast. Он делает так, что при сжатии изображений не теряется ни одна деталь — обеспечивая пиксель-к-пикселю воссоздание оригинального изображения. Эта функция обеспечивает максимальную четкость изображения, гарантируя, что конечные пользователи получают лучший опыт использования. С бинарным lossless-режимом Blast пользователи в критически важных областях, таких как здравоохранение, могут быть уверены, что их изображения, включая рентгеновские снимки и другие детализированные сканы, передаются без потери информации.

4. Увеличение персонализации с помощью настраиваемых фонов Microsoft Teams

Horizon 2312 получил новую функцию, позволяющую ИТ-администраторам загружать подборку одобренных фонов для Microsoft Teams, включая фирменные или другие тематические фоны. С этим обновлением конечные пользователи могут выбирать из этих предварительно одобренных фонов для настройки своего виртуального пространства для встреч, обеспечивая более персонализированный подход при сохранении профессионального вида.

5. Размытие фона для клиента Linux

Этот выпуск вводит возможность размывать фон во время встреч в Microsoft Teams для клиентов Linux. Это улучшение повышает качество встреч для конечных пользователей, предлагая слой конфиденциальности и минимизируя отвлекающие факторы.

6. Модуль FIPS для MacOS

Для клиентов, требующих модуль обработки федеральных стандартов информации (FIPS) для macOS, клиент Horizon MacOS использует шифры, соответствующие FIPS.

7. Упрощенное развертывание Horizon Linux с помощью инструмента легкой настройки

Horizon 2312 получил легкую настройку для агента Horizon Linux. Этот новый инструмент предназначен для упрощения процесса установки с помощью CLI-инсталлятора и руководства администратора. Он предлагает пошаговый подход к развертыванию агента Horizon Linux, облегчая более гладкую и эффективную настройку. С помощью инструмента легкой настройки администраторы ИТ теперь могут без труда устанавливать агент, упрощая и обеспечивая успешное развертывание в операционной системе Linux.

8. Улучшения режима эмуляции, совместимого с ARM, для клиента Windows

На основе релиза Horizon 2309, который добавил поддержку режима эмуляции, совместимого с устройствами на базе ARM, решение Horizon 2312 предоставляет дополнительную функциональность с поддержкой «Login as Current User» (LACU). Эта функция, эксклюзивная для Windows, упрощает рабочие процессы для устройств, входящих в домен, используя функциональность LACU, чтобы позволить пользователям запускать Horizon без необходимости повторной аутентификации. Поддержка Horizon для ARM предоставляет клиентам больше выбора оборудования для их конечных пользователей, предлагая больше вариантов аппаратного обеспечения и обеспечивая операционную эффективность.

9. Возможность блокировки SendKey для защиты ВМ от вредоносных скриптов

Horizon 2312 вводит возможность блокировать скрипты PowerShell и другие скрипты SendKey от передачи с устройства пользователя в виртуальную машину. Блокируя скрипты от отправки вредоносных нажатий клавиш, эта функция предотвращает манипуляции злоумышленников с сессией конечного пользователя. Доступная для Horizon Client for Windows, эта защитная мера помогает предотвратить потенциальные атаки типа "отказ в обслуживании" (DoS) и внедрение вредоносного программного обеспечения, обеспечивая безопасность виртуальных сессий.

10. Интеграция DEEM улучшает возможности телеметрии Horizon

Horizon интегрировал возможности управления цифровым опытом сотрудников (DEEM) для улучшения аналитики по опыту сотрудников. Horizon будет предоставлять информацию, связанную с сессией, агенту DEEM, оптимизируя сбор и передачу телеметрии ВМ внутри гостевой системы напрямую в Workspace ONE Intelligence. С этим обновлением агент Horizon делится телеметрией гостевой ОС — такой как ID сессии Horizon, ID пула и имя пула — с агентом DEEM, предоставляя набор данных, доступных для анализа. Собранная информация о производительности ВМ и опыте пользователя позволяет администраторам превентивно решать проблемы, оптимизировать ресурсы и улучшать общий опыт пользователя. Эта интеграция DEEM и агента Horizon в настоящее время находится в бета-тестировании до конца марта 2024 года. Если вы заинтересованы в участии в бета-программе, то можно зарегистрироваться тут.

Новые возможности платформы Horizon 2312

Теперь, когда мы рассмотрели все новшества в клиентах и агентах Horizon, давайте обсудим новые функции платформы, которые подтверждают приверженность VMware улучшению операций, обеспечению безопасности взаимодействий пользователей и расширению возможностей для удовлетворения потребностей администраторов.

1. Права доступа Horizon Cloud

Horizon 2312 позволяет конечным пользователям получать права доступа как из Horizon 8, так и из Horizon Cloud Service (HCS). Пользователи могут входить в локальный сервер подключения Horizon с использованием своих учетных данных без необходимости повторного входа для доступа к тем же правам на рабочие столы и приложения в облаке. Эта интеграция устраняет необходимость в использовании множества URL, выходов и дополнительных входов в систему при переключении между локальными и облачными рабочими столами, синхронизируя права доступа в обеих средах. Конечные пользователи могут аутентифицироваться через клиент Horizon для Windows или HTML Access, получить свои права Horizon 8 и затем получить доступ к своим правам Azure в Horizon Cloud Next-Gen с использованием токена JWT. Для получения дополнительной информации обращайтесь сюда.

2. Интуитивно понятный графический интерфейс для функции форензики

На основе функции форензики, представленной в релизе Horizon 2206, которая позволяет сохранять непостоянные ВМ для последующего просмотра, Horizon 8 теперь добавил графический пользовательский интерфейс (GUI). Специально разработанный для рабочих столов Instant Clone, этот интуитивно понятный графический интерфейс предоставляет информацию, связанную с пользователем, и детали форензических действий внутри ВМ. Новый графический интерфейс служит мостом, добавляя видимость и простоту к процессам расследований в виртуальных средах.

Функции форензики могут быть применены к пользователям или группам:

Отдельные машины пользователя или группы можно выбрать для более детального изучения:

3. Оптимизированная база данных ADAM для улучшения производительности репликации

В связи с ростом баз данных Active Directory Application Mode (ADAM), Horizon 2312 предлагает решение, направленное на уменьшение размера базы данных за счет сокращения периода "tombstone-lifetime" для уменьшения времени репликации. Ранее удаленные объекты сохранялись в течение 180 дней, что приводило к увеличению базы данных и удлинению времени репликации. В версии 2312 этот период сокращается до 60 дней, что приведет к уменьшению размера базы данных, ускорению репликации и повышению надежности работы системы. Кроме того, это помогает сократить время, необходимое для полной репликации базы данных ADAM, например, при добавлении Connection Server в существующую среду.

4. Настройка маршрутизации RDSH для опубликованных приложений и рабочих столов

Для предоставления администраторам более точного контроля во время тестирования и устранения неполадок, Horizon 2312 позволяет использовать опубликованные приложения и рабочие столы для направления пользователей на конкретные RDSH в рамках фермы. Эта функциональность сделана в ответ на потребности заказчиков — будь то для проверки и мониторинга всего процесса end-to-end или для проведения теста на каждом RDSH внутри фермы. Эта функция активируется в настройках опубликованного приложения или рабочего стола и требует использования параметра командной строки клиента Horizon для Windows. Функция также доступна для выбора конкретной виртуальной машины из пула non-persistent рабочих столов.

5. Автоматизированное обслуживание мгновенных клонов с автоматическим отключением хостов RDS

В обновлении Horizon 2313 автоматически отключаются отдельные хосты RDS в фермах мгновенных клонов RDS при выполнении обслуживания и использовании опции "Wait for users to logoff". Ранее администраторам приходилось вручную вмешиваться, чтобы отключить хосты для обслуживания. Теперь система автоматизирует этот процесс, оставляя достаточное количество хостов RDS включенными для поддержания доступа пользователей, позволяя другим хостам RDS освобождаться и обновляться.

6. Политика приостановки питания для мгновенных клонов с vGPU

Применение политик управления питанием полезно для экономии ресурсов, когда ВМ не используются. В Horizon 2312 администраторы могут использовать политику приостановки удаленной машины для пулов мгновенных клонов с поддержкой NVIDIA vGPU. Эта функция активируется ESXi, который поддерживает политики приостановки/возобновления питания для ВМ с vGPU. Отметим, что только версии ESXi 6.7 или выше поддерживают эту функцию.

7. Настройка текста запроса на сброс пароля в консоли администратора

Для улучшения соответствия протоколам безопасности организации, Horizon 2312 вводит возможность для администраторов отображать настраиваемые сообщения политики во время операций сброса пароля. Это обновление, доступное из консоли администратора, помогает снизить количество неудачных попыток сброса пароля, предоставляя пользователям четкие напоминания о требованиях к политике паролей. Когда пользователи пытаются изменить свои пароли, и выбранный пароль не соответствует установленным критериям, система теперь представит настроенное сообщение, описывающее конкретные требования к паролю.

Настроенное сообщение будет показано при неудачной попытке изменения пароля:

8. Завершена модернизация API с полным переходом на REST

Horizon 2312 завершает переход с API, основанных на SOAP, на REST API с полным сохранением функциональности предыдущих SOAP API. Все новые RESTful API можно загрузить с сайта API сервера Horizon.

9. Архитектура vSAN Express Storage

Horizon 8 2309 начал поддерживать vSAN 8 Express Storage Architecture (ESA) как для полных, так и для мгновенных клонов. Сейчас эта поддержка была улучшена. vSAN ESA — это новая, опциональная архитектура хранения, введенная в vSAN 8. Кроме того, с этой новой поддерживаемой архитектурой, Horizon может поддерживать до 500 ВМ на хост ESXi в зависимости от рабочей нагрузки и конфигурации оборудования. vSAN 8 предоставляет клиентам свободу выбора, какую из двух архитектур (vSAN OSA или vSAN ESA) использовать, чтобы лучше всего удовлетворить их потребности. vSAN ESA обеспечивает новые уровни производительности, масштабируемости, надежности и простоты использования на базе высокопроизводительных устройств хранения. Чтобы узнать больше почитайте вот эту статью блога VMware.

На этом обзор основных моментов релиза Horizon 2312 закончен. Для полного ознакомления со всеми улучшениями обратитесь к Horizon 8 2312 Release Notes.

Ransomware стало настоящей напастью последних лет - выплаты компаний злоумышленникам, зашифровавшим данные и держащим их в заложниках, перевалили за миллиард долларов в прошлом году (и это только то, что известно). Серверы VMware ESXi и vCenter, являющиеся основными компонентами инфраструктуры vSphere, представляют главную мишень для атак Ransomware.

В рамках конференции VMware Explore Europe 2023 прошла интересная сессия, где рассматривались примеры из реального мира по борьбе с программами-вымогателями, а также обсуждались проактивные методики, которые позволят избежать атаки или минимизировать последствия:

Вот основные выводы, которые суммаризуют выступление выше:

1. vSphere является привлекательной целью для атак программ-вымогателей, что делает крайне важной защиту вашей среды vSphere от таких угроз.

2. Важно провести различие между защитой рабочих нагрузок (виртуальные машины, серверы, клиенты, AD) и защитой инфраструктурной платформы (vSphere, хранилище и т.д.), поскольку каждое требует различных мер безопасности. Эти аспекты должны быть отделены друг от друга.

3. Понимание путей атаки, ведущих к появлению программы-вымогателя в инфраструктуре vSphere, является ключевым. Эти пути включают начальный доступ, использование Active Directory и различные способы добраться и атаковать vCenter Server и ESXi.

4. Восстановление среды vSphere после атаки не должно включать в себя выплату выкупа. Платеж атакующим увеличивает риск будущих атак и не гарантирует полного решения проблемы.

5. Наличие и целостность резервных копий критически важны для восстановления. Важно обеспечить, чтобы резервными копиями нельзя было манипулировать и что их можно было успешно восстановить.

6. Очистка и восстановление скомпрометированных компонентов, таких как виртуальные машины, vCenter Server и хосты ESXi после атаки, требует тщательного рассмотрения и технического анализа (форензика).

7. Для защиты vSphere от атак должны быть предприняты несколько мер, включая сегментацию vSphere от рабочих нагрузок и клиентов, использование EDR/XDR/SIEM для конечных точек и vSphere, установку обновлений безопасности и следование рекомендациям по защите платформы vSphere.

8. Предотвращение выполнения стороннего кода в ESXi может быть достигнуто через настройки, такие как execInstalledOnly, которые предотвращают выполнение нежелательных файлов и скриптов.

9. UEFI Secure Boot может использоваться для проверки целостности файлов загрузки и ядра ESXi, что защищает от угроз с использованием неподписанных VIB.

10. Деактивация доступа к Shell для не-root пользователей ESXi может предотвратить боковое движение от vCenter к ESXi, что является важной мерой для остановки или замедления атакующего.

Конструктор лаборатории VMware Cloud Foundation Lab Constructor (VLC) Holodeck Toolkit предназначен для обеспечения масштабируемого, повторяемого способа развертывания вложенных сред VMware Cloud Foundation (VCF) непосредственно на хостах VMware ESXi. Эти среды идеально подходят для практических занятий нескольких команд, изучающих возможности VCF и реализации управляемого заказчиком облака VMware.

В зависимости от числа необходимых тестовых окружений, вам понадобится мощный сервер в одной из следующих конфигураций:

Реализация лабораторий VCF во вложенной форме решает несколько проблем, связанных с практическими занятиями для продукта уровня центра обработки данных, такого как VCF, включая:

• Снижение требований к оборудованию - при работе в физической среде VCF требует четыре узла vSAN Ready Nodes для домена управления и дополнительные хосты для создания кластеров и доменов рабочих нагрузок. Во вложенной среде те же четыре-восемь хостов легко виртуализируются для работы на одном хосте ESXi.
• Самодостаточные сервисы - конфигурация Holodeck Toolkit предоставляет общие инфраструктурные сервисы, такие как NTP, DNS, AD, сервисы сертификатов и DHCP внутри среды, исключая необходимость полагаться на сервисы центра обработки данных во время тестирования. Каждой среде требуется один внешний IP.
• Изолированная сеть - конфигурация Holodeck Toolkit устраняет необходимость в соединениях VLAN и BGP в сети клиента на ранних этапах тестирования.
• Изоляция между средами - каждая развертываемая среда Holodeck полностью самодостаточна. Это избегает конфликтов с существующими сетевыми конфигурациями и позволяет развертывать множество вложенных сред без опасений насчет перекрытия.
• Множественные развертывания VCF на одном хосте VMware ESXi с достаточной мощностью - типичное развертывание стандартной архитектуры VCF с четырехузловым доменом управления и четырехузловым доменом рабочих нагрузок VI, а также дополнениями, такими как VMware vRealize Automation, требует примерно 20 ядер процессора, 512 ГБ памяти и 2.5 ТБ диска.
• Автоматизация и повторяемость - развертывание вложенных сред VCF почти полностью автоматизировано и легко повторяемо с использованием файлов конфигурации. Типичное развертывание занимает менее 3 часов, с менее чем 15 минутами активного времени использования клавиатуры.

Среда Holodeck Toolkit 2.0

Пакет Holodeck Toolkit 2.0 состоит из нескольких основных компонентов:

• Пакет VCF Lab Constructor (VLC) 5.0 для полной автоматизации развертывания повторяемых вложенных лабораторий Cloud Foundation на одном хосте ESXi. Этот релиз поддерживает VCF 4.5, 4.5.1 и 5.0.
• Пользовательские файлы конфигурации VLC-Holo-Site-1 и VLC-Holo-Site-2 для VLC, поддерживающие развертывания VMware Cloud Foundation с несколькими сайтами.
• Пользовательский Holo-Router на базе VMware Photon OS для поддержки коммуникаций внутри вложенной среды VCF и из этой среды во внешнюю сеть.
• Пользовательская Holo-Console на базе Microsoft Windows Server 2019.
• Полностью автоматизированный механизм создания ISO-образа Holo-Console.
• Полные руководства по развертыванию и эксплуатации одного или нескольких серверов Holodeck.
• Набор лабораторий Holodeck "Always succeed" для демонстрации модели облачной эксплуатации нескольким командам внутри центра обработки данных.
• Программно-определенные сети и безопасность с VMware NSX Data Center.
• Автоматизация частного облака на базе VMware Cloud Foundation.
• Масштабирование развертывания и мониторинга приложений с VMware vRealize Automation.
• Миграция рабочих нагрузок с VMware HCX.
• Модернизация приложений с VMware Tanzu.

Обзор VCF Lab Constructor (VLC)

VLC - это утилита PowerShell/PowerCLI, разработанная для автоматизации развертывания VMware Cloud Foundation во вложенной среде. VLC, используемый с конфигурацией Holodeck, автоматизирует предоставление стандартизированной среды Holodeck "Pod".

Каждый Pod Holodeck содержит:

• Четырехузловой домен управления VCF на вложенных узлах, готовых к использованию с vSAN.
• Опционально три дополнительных вложенных хоста в домене рабочих нагрузок - или второй кластер vSphere в домене управления, или просто дополнительные элементы первого.
• NSX полностью настроен.
• Развернутый AVN/NSX Edge (рекомендуется).
• Развернутый Tanzu (опционально).
  
• VM Cloud Foundation Cloud Builder, настроенный для предоставления DHCP, NTP, DNS, BGP peering и L3 маршрутизации внутри пода.

VLC также может автоматизировать развертывание второго экземпляра VCF на под для предоставления многосайтовой конфигурации VCF для продвинутых лабораторных занятий, таких как NSX Federation, VMware Site Recovery Manager и VCF с vSAN Stretched Cluster.

VLC предоставляет возможность развертывания вложенных сред с простым графическим интерфейсом или полностью автоматизированно с файлом конфигурации и командной строкой PowerShell. Масштабирование работающих вложенных сред (добавление дополнительных вложенных хостов ESXi) может быть выполнено с помощью опции пакета расширения в графическом интерфейсе VLC.

Примечание: VCF Lab Constructor не поддерживается VMware как официальный продукт, это что-то похожее на VMware Flings. Вы также можете присоединиться к каналу поддержки VLC в Slack.

Обзор вложенной среды

Конфигурация "VLC Holodeck Standard" является вложенной конфигурацией VMware Cloud Foundation, используемой в качестве базовой для нескольких лабораторных упражнений по эксплуатации частного облака, созданных командой технического маркетинга Cloud Foundation. Стандартный "VLC-Holo-Site-1" является основной развертываемой конфигурацией. Дополнительный VLC-Holo-Site-2 может быть развернут в любое время позже в рамках нового Pod. Конфигурация VLC-Holo-Site-1 соответствует лабораторной конфигурации в VCF Hands-On Lab HOL-2246 и вложенной конфигурации в программе VCF Experience, запущенной на платформе лабораторий VMware.

Каждый Pod в развертывании Holodeck работает с идентичной вложенной конфигурацией. Pod может быть развернут с автономной конфигурацией VLC-Holo-Site-1 или же с одновременно активными конфигурациями VLC-Holo-Site-1 и VLC-Holo-Site-2. Разделение подов, а также между сайтами внутри пода, обрабатывается на уровне виртуального коммутатора vSphere Standard Switch (VSS). Каждый Pod Holodeck настроен с уникальным VSS для сайта. Группа портов VMware vSphere настроена на каждом VSS и сконфигурирована как транк VLAN.

• Компоненты в группе портов используют тегирование VLAN для изоляции коммуникаций между вложенными VLAN. Это устраняет необходимость в физических VLAN, подключенных к хосту ESXi для поддержки вложенных лабораторий.
• Когда развертывается конфигурация Holo-Site-2, она использует второй VSS и группу портов для изоляции от Holo-Site-1.
• Конфигурация VLC Holodeck настраивает виртуальную машину VCF Cloud Builder для предоставления нескольких сервисов поддержки внутри пода, чтобы не требовать дополнительных сервисов со стороны клиента. VM Cloud Builder развертывается на сайт для предоставления следующих услуг внутри пода:
  • DNS (локально для Site1 и Site2 внутри пода, действует как промежуточный узел).
  • NTP (локально для Site1 и Site2 внутри пода).
  • DHCP (локально для Site1 и Site2 внутри пода).
  • L3 TOR для сетей vMotion, vSAN, управления, Host TEP и Edge TEP в каждом сайте.
  • BGP-пир с VLC Tier 0 NSX Application Virtual Network (AVN) Edge (обеспечивает подключение к оверлей-сетям NSX из лабораторной консоли).

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-1 внутри Pod Holodeck. Конфигурация Site-1 использует домен DNS vcf.sddc.lab и VLAN 10-15.

Пакет Holodeck также предоставляет предварительно настроенную виртуальную машину Photon OS, называемую "Holo-Router", которая функционирует как виртуализированный маршрутизатор для базовой среды. Эта ВМ позволяет соединять вложенную среду с внешним миром. Holo-Router настроен на перенаправление любого трафика Microsoft Remote Desktop (RDP) к вложенному jump-хосту, известному как Holo-Console, который развертывается внутри пода.

Интерфейс пользователя для вложенной среды VCF предоставляется через виртуальную машину Windows Server 2019 "Holo-Console". Holo-Console предоставляет место для управления внутренней вложенной средой, подобно рабочему столу системного администратора в центре обработки данных. Holo-Console используется для запуска пакета VLC для развертывания вложенного экземпляра VCF внутри пода. Виртуальные машины Holo-Console развертываются из специально созданного ISO, который настраивает следующее:

1. Microsoft Windows Server 2019 Desktop Experience, имеющий на борту:

• Домен Active directory "vcf.holo.lab"
• DNS-форвардер к Cloud Builder
• Сервер сертификатов, Web Enrollment и шаблон сертификата VMware
• Включенный RDP
• Настроенный IP, подсеть, шлюз, DNS и VLAN для развертывания как Holo-Console
• Отключенный брандмауэр и улучшенная безопасность IE
• Настроенное рабочее окружение SDDC Commander

2. Дополнительные программные пакеты, развернутые и настроенные:

• Google Chrome с закладками Holodeck
• VMware Tools
• VMware PowerCLI
• VMware PowerVCF
• VMware Power Validated Solutions
• Клиент PuTTY SSH
• VMware OVFtool

3. Дополнительные программные пакеты, скопированные в Holo-Console для последующего использования:

• VMware Cloud Foundation Cloud Builder OVA в C:\CloudBuilder.

4. VCF Lab Constructor 5.0 с двойной конфигурацией Holodeck:

• C:\VLC\VLC-Holo-Site-1
• C:\VLC\VLC-Holo-Site-2

5. VMware vRealize Automation 8.10 Easy Installer

На рисунке ниже показаны виртуальные машины, работающие на физическом хосте ESXi для предоставления пода Holodeck под названием "Holo-A". Обратите внимание на экземпляры Holo-Console, Holo-Router, Cloud Builder и четыре вложенных хоста ESXi. Они все общаются через группу портов VLC-A-PG.

Добавление второго сайта включает дополнительный экземпляр Cloud Builder и дополнительные вложенные хосты ESXi. VLC-Holo-Site-2 подключается ко второй внутренней линии Holo-Router на VLAN 20. Доступ в сеть из Holo-Console к VLC-Holo-Site-2 осуществляется через Holo-Router.

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-2 внутри пода Holodeck. Конфигурация Site-2 использует домен DNS vcf2.sddc.lab и VLAN 20-25.

Доступ к среде Holodeck

Доступ пользователей к поду Holodeck осуществляется через Holo-Console. Доступ к Holo-Console возможен двумя способами:

1. Подключение через Microsoft Remote Desktop Protocol (RDP) к внешнему IP Holo-Router. Holo-Router настроен на перенаправление всего RDP-трафика к экземпляру Holo-Console внутри пода:

• Клиент Microsoft Remote Desktop для Mac
• Клиент Remote Desktop для Windows (доступен в Microsoft Store)

2. Доступ к Holo-Console через хост ESXi:

• Консоль браузера (встроенная в клиент vSphere)
• VMware Remote Console (требуется вход в VMware Customer Connect)

Предварительные требования для развертывания VLC Holodeck

Размер хоста ESXi:

• Good (один под): Один хост ESXi с 16 ядрами, 384 ГБ памяти и 2 ТБ SSD/NVME
• Better (два пода): Один хост ESXi с 32 ядрами, 1024 ГБ памяти и 4 ТБ SSD/NVME
• Best (четыре или более подов): Один хост ESXi с 64+ ядрами, 2.0 ТБ памяти и 10 ТБ SSD/NVME

Конфигурация хоста ESXi:

• vSphere 7.0U3 или 8.0
• Виртуальный коммутатор и группа портов, настроенные с подключениями к сети клиента/интернету
• Поддерживается автономный хост, не управляемый сервером vCenter, и одноузловой кластер, управляемый экземпляром сервера vCenter
• Кластеры с несколькими хостами НЕ поддерживаются в этом выпуске из-за требования физической поддержки VLAN

Хост Holo-Build:

• Хост Windows 2019 или VM с локальным доступом к хостам ESXI, используемым для Holodeck + доступом в интернет для загрузки программного обеспечения. (Этот пакет был протестирован только на Microsoft Windows Server 2019)
• 200 ГБ свободного дискового пространства
• Действительный вход в CustomerConnect
• Лицензия на VCF 4.5 или 5.0 Enterprise для минимум 8 хостов (16 хостов, если планируется тестирование Cloud Foundation Multi region с NSX Federation)

Ключи лицензий для следующих компонентов VCF 4.5 или 5.0 (на данный момент Toolkit Holodeck не поддерживает подписочные лицензии):

• VMware Cloud Foundation
• VMware NSX-T Data Center Enterprise
• VMware vSAN Enterprise
• VMware vSphere Enterprise Plus
• VMware vCenter Server (одна лицензия)
• VMware vRealize Suite Advanced или Enterprise (теперь это VMware Aria Suite)

Требуемые внешние/клиентские сети:

• IP-адрес управления хоста ESXi (один на хост)
• Адрес Holo-Router на под

Требуемое программное обеспечение (ссылки и инструкции есть в модуле создания пользовательского ISO Holodeck):

• Microsoft Server 2019 Desktop Experience (Eval копия с истечением срока действия через 6 месяцев)
• Свежий пакет VMware VMTools
• Отдельная установка Google Chrome
• Последний архив VMware PowerCLI
• Свежий архив VMware PowerVCF
• Свежий модуль VMware Power Validated Solutions Module
• Свежий MSI клиента PuTTY SSH
• Свежий VMware OVFtool (требуется вход в CustomerConnect)
• VMware Cloud Foundation 4.5 или 5.0 Cloud Builder OVA (требуется вход в CustomerConnect)
• Архив VLC holodeck-standard-main zip - включает VCF Lab Constructor, Holo-Router.ova, скрипты автоматизации поддержки Holodeck и руководства по развертыванию в файле holodeck-standard-main.zip
• Notepad ++ 8.4.7
• VMware vRealize Automation 8.11.2 Easy Installer (требуется вход в CustomerConnect) - эта лаборатория разработана для работы только с VMware vRealize Automation 8.11.2.

Полезные ссылки

• Holodeck 2.0 Setup
• SDDC Manager Operations
• Software-Defined Networking
• Cloud Operations
• Tanzu Operations
• Exploring Holodeck

VMware Cloud Foundation 5.1 и vSAN 8 Update 2 вносят новые улучшения в архитектуру хранения данных vSAN Express Storage Architecture (ESA), которые помогают лучше понять потребление емкости в кластерах.

Часто задаваемые вопросы администраторов

Когда речь идет о хранении данных, основные вопросы, которые задают себе архитекторы центров обработки данных - это "сколько емкости хранения я купил?", "сколько я использую?" и "сколько у меня осталось?". Хотя ответы кажутся очевидными, системы хранения данных часто полагаются на множество способов обеспечения надежности данных и часто используют возможности повышения эффективности использования пространства, что иногда может затруднить ответы на эти вопросы.

Стек хранения данных ESA обрабатывает и хранит данные иначе, чем Original Storage Architecture (OSA). В результате, его накладные расходы на хранение метаданных, файловых систем и необходимая емкость для обеспечения надежности хранения основных данных на случай сбоя также отличаются. Недавние улучшения в vSAN 8 U2 и VMware Cloud Foundation 5.1 включают изменения в пользовательском интерфейсе, которые позволяют лучше учитывать эти накладные расходы. Эти улучшения упрощают понимание потребления емкости. Давайте посмотрим, что изменилось и рассмотрим пример использования емкости хранения для ESA.

Пример потребления храненилищ в ESA

Кластер в примере ниже состоит из 8 хостов ESXi, работающих на платформе vSAN 8 U2. Каждый хост оснащен четырьмя устройствами хранения емкостью 1.6 ТБ, обеспечивая чуть менее 6 ТБ на хост или примерно 47 ТБ для кластера. В этом кластере ESA работает около 100 виртуальных машин, каждой из которых назначена специфичная для кластера политика хранения данных по умолчанию с RAID-6 под управлением функции автоматического управления политиками vSAN ESA. Также там включена функция возврата пространства хранилищ TRIM/UNMAP vSAN. Для ясности, в этом кластере не включены механизмы управления емкостью операционного резерва и резерва восстановления хоста (Operation's Reserve и Host Rebuild Reserve). Хотя этот пример использует кластер в варианте развертывания vSAN HCI, результаты будут такими же, как и в кластере, работающем на vSAN Max.

vSAN представляет емкость кластера на странице Summary, которая делится на два раздела. Раздел "Capacity Overview" показывает, сколько доступной емкости используется, а "Usage breakdown" подробно описывает тип данных, в настоящее время хранящихся в кластере.

Представление Capacity Overview

В этом примере пользовательский интерфейс показывает, что кластер предоставляет 46.57 ТБ отформатированной сырой емкости. Маленькая вертикальная линия на графике обзора емкости представляет "порог операций" (operations threshold), который отражает рекомендуемый лимит потребления емкости (в данном случае - 38.27 ТБ), который обеспечивает операционную деятельность vSAN.

Хотя на кластере хранится почти 31 ТБ данных гостевых виртуальных машин, метаданных объектов и снимков, фактически используемая емкость составляет 17.69 ТБ после учета сжатия данных, что экономит 13.70 ТБ. Сжатие данных в ESA гораздо лучше, чем в OSA, но, конечно, коэффициенты сжатия, которых вы достигнете, будут полностью зависеть от типа данных, хранящихся в вашей среде.

Представление Usage breakdown

В разделе "Usage breakdown" подробно описывается распределение данных после сжатия, исключая свободную емкость. Нововведением в vSAN 8 U2 и VMware Cloud Foundation является значение "ESA object overhead" в категории "System usage". Она отображает метаданные, создаваемые в отношении объекта и реплицированных данных. В этом примере оно составляет около 11.96% от хранимых данных. Указанные накладные расходы объекта ESA рассчитываются после сжатия данных, так что чем лучше сжатие, тем меньше необходимо накладных расходов.

Рекомендация: используйте представление "Usage breakdown" только для хорошо заполненных кластеров. Поскольку расчет ведется только по записанным данным, новые кластеры, в которых очень мало или вообще нет виртуальных машин, могут показывать проценты накладных расходов, гораздо выше ожидаемых. Это связано с тем, что в кластере кроме стандартных, глобальных системных накладных расходов, практически нет других данных.

Результат

Этот конкретный пример демонстрирует, что ESA, даже после учета различных накладных расходов, может защищать данные с высоким уровнем устойчивости (FTT=2) таким образом, что практически все накладные расходы на отказоустойчивость и метаданные компенсируются. В этом примере на кластере, который предоставляет около 46 ТБ сырой емкости, было примерно 15 ТБ данных гостевых виртуальных машин, которые после учета накладных расходов и сжатия потребовали около 17,7 ТБ сырого хранилища. Предполагая тот же уровень сжатия для новых данных, можно было бы хранить еще 15 ТБ дополнительных данных в высокоустойчивом виде и оставаться в пределах базового порога операций для кластера в 38.27 ТБ.

По сравнению с OSA, ESA обеспечивает более высокую устойчивость (поскольку большинство клиентов используют менее устойчивый FTT=1 вместо FTT=2 на OSA), гораздо более высокую производительность и улучшенную эффективность использования пространства для снижения затрат. Intel недавно опубликовала материал, который подтверждает это мнение: "Beyond Savings:  How Server Consolidation with VMware vSAN 8 Boosts Performance by more than 7.4x!". И в отличие от традиционного модульного массива хранения, вы получаете полностью распределенную систему хранения, которую можно масштабировать постепенно и экономично, используя ваши любимые серверы.

Оценка требований к хранению данных

Как вы можете применить эти знания при планировании собственной среды? Утилита vSAN ReadyNode Sizer делает все расчеты необходимой емкости за вас. На рисунке ниже показано, что когда введены спецификации серверов и коэффициенты сжатия, чтобы они соответствовали этому кластеру, оценки емкости оказываются очень похожими.

С выходом обновленной версии VMware vSAN 8 в этом решении появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

Дункан Эппинг в ответ на запрос пользователей решения vSAN ESA сделал интересный пост на тему минимально необходимого числа хостов, которое требуется для поддержания определенного уровня избыточности - RAID-0/1/5/6.

В VMware vSAN 8 Update 1 появился адаптивный алгоритм записи, который существенно уменьшает избыточность записи на RAID-конфигурации. Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

Теперь для vSAN ESA на базе RAID-5, в зависимости от размера кластера, могут быть использованы конфигурации 2+1 или 4+1, а конфигурация 3+1 больше не поддерживается. При этом для RAID-1 и RAID-6 в конфигурациях ничего не изменилось.

Ну и, собственно, ниже приведена таблица, которая позволит вам понять, какое минимальное число хостов ESXi нужно использовать для каждой из выбранных конфигураций, и как это сказывается на дополнительных затратах дисковой емкости:

Когда мы рассказывали о нововведениях в продуктовой линейке VMware на 2024 год, мы упоминали, что компания в составе Broadcom решила полностью перейти на модель подписки на свои продукты (VMware Cloud Foundation и VMware vSphere Foundation), исключив "вечные" (perpetual) лицензии и поддержку. Также к этим продуктам можно докупать аддоны, которые лицензируются отдельно, в зависимости от типа аддона.

На днях VMware объявила об этом официально. Подробную информацию о данном переходе можно найти в KB 96168.

Кроме того, VMware от Broadcom также планирует предложить возможность использовать уже имеющиеся купленные лицензии в рамках программы Bring Your Own License, которая позволит клиентам получать новые подписки на VMware Cloud Foundation от Broadcom и гибко использовать эти подписки в проверенных гибридных облачных средах VMware, а также в собственных локальных датацентрах.

Еще одним результатом этого перехода является то, что продукты, перечисленные в таблице ниже, теперь находятся на стадии снятия с производства (End of Availability, EOA) в качестве отдельных продуктов. Некоторые предложения все еще могут быть доступны для использования в рамках решений VMware Cloud Foundation (VCF) или VMware vSphere Foundation (VVF), что отмечено отдельно.

VMware также объявляет об окончании доступности (EOA) услуг Aria SaaS, но продолжит поддерживать клиентов, в настоящее время использующих эти услуги, до конца срока их подписки. По истечении срока подписки клиентам нужно будет перейти на использование либо VCF, либо VVF. Также обратите внимание, что услуги Aria SaaS находятся в режиме maintenance mode, что означает, что новые функции не будут доступны, хотя обновления безопасности и критические обновления будут предоставляться в течение активного периода подписки.

Это объявление охватывает все варианты лицензирования, включая Perpetual, поддержку и подписку (Support & Subscription, SnS), SaaS/хостинг и другие типы подписок. Оно также касается каждого издания, пакета и модели ценообразования для каждого продукта. Любое исключение из этого правила будет указано отдельно.

Эта таблица позволит вам понять сущность перехода от старых продуктов на новые:

Обратите внимание, что бесплатного решения VMware ESXi (vSphere Hypervisor) больше нет! За все надо платить)

Если вы являетесь существующим клиентом и приобрели продукты, которые сейчас находятся на стадии окончания доступности (End of Availability), но ваша подписка пока не подлежит обновлению, в настоящее время никаких немедленных действий не требуется. VMware будет продолжать предоставлять активную поддержку на протяжении всего срока вашего договора поддержки. В будущем, в момент обновления подписки, вы можете работать со своим представителем или партнером VMware, чтобы согласовать ваши дальнейшие требования с обновленным портфелем предложений VMware.

На днях компания VMware выпутсила большое обновление утилиты vSphere Diagnostic Tool версии 2.0.1, которая теперь называется VCF Diagnostic Tool for vSphere (VDT). Напомним, что это python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance, где скрипт и нужно запускать), а также в перспективе это будет работать и в среде VMware ESXi. О предыдущем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.

VDT 2 был переписан с нуля с целью эволюции от простой коллекции скриптов на Python к фреймворку для отчётности о состоянии инфраструктуры на основе Python. Новая версия предоставляет библиотеки, которые стандартизируют вывод и формат каждой проверки. Это означает, что скоро будет доступна совместимость с дополнительными продуктами от VMware.

Итак, с помощью скрипта вы сможете выполнить следующие проверки состояния инфраструктуры:

• Вывод базовой информации о vCenter
• Проверки SSO (Lookup Service и Machine ID)
• Интеграция с Active Directory
• Сертификаты vCenter
• Функциональность VMdir
  
• Core-файлы
• Использование базы данных vPostgres
• Использование дискового пространства
• Функционирование DNS
• Синхронизация времени и функционирование NTP
• Валидность аккаунта Root
• Службы vCenter
• Проверка механизма VCHA
  
• Функционирование Syslog
• Проверки IWA/AD
• Проверка Local Identity Source

Для начала работы вы можете воспользоваться следующими статьями базы знаний VMware

• Using the VCF Diagnostic Tool for vSphere (VDT) (83896)
• Using the VCF Diagnostic Tool on SDDC Manager (94141)

Скачать VCF Diagnostic Tool for vSphere можно из KB 83896 в правой колонке:

Утилита VDT запускается простой командой из консоли:

При работе скрипта будет запрошен пароль для учетной записи administrator@sso.domain, но и без него многие проверки будут выполнены успешно.

Mateusz Romaniuk написал отличный пост о том, что делать, когда вы провели апгрейд решения для создания отказоуйстойчивых хранилищ с версии VMware vSAN 8 Update 1 на Update 2.

VMware vSphere 8.0 U2 вносит множество улучшений, исправляет несколько проблем и повышает стабильность. После обновления с vSphere 8.0 U1 на U2 происходят также некоторые изменения в vSAN. Если кластер vSAN работает в производственной инфраструктуре, вам необходимо проапгрейдить версию диска, когда вы используете самую новую версию vSphere.

В итоге у вас должна быть версия 19 для формата дисков кластера vSAN (Disk format version):

Итак, сам процесс обновления:

1. В клиенте vSphere выберите ваш кластер vSAN. Перейдите на вкладку Configure и в разделе vSAN выберите Disk Management. Если вы проверите один из хостов ESXi, работающих на vSAN, вы увидите, что текущая версия диска - 18.0.

2. Запустите процедуру предварительной проверки Pre-Check Upgrade, чтобы убедиться, что формат дисков может быть обновлен:

3. Если все в порядке, то нажимайте кнопку Upgrade:

4. После этого начнется процесс апгрейда формата дисков, продолжительность которого зависит от размера вашей инфраструктуры и количества дисков:

5. После апгрейда вы получите уведомление об успешном завершении, а в разделе Disk Management вы можете выбрать хост ESXi и нажать View Disks:

6. Там в разделе Disk group вы и увидите нужную вам информацию - Disk format version: 19

Ну а вот и сами диски дисковой группы:

В мае 2022 года компания Broadcom объявила о приобретении компании VMware за 61 миллиард долларов, что стало новым этапом в развитии главного вендора в сфере виртуализации. Данное поглощение стало вторым по цене за 2022 год — еще большую цену предложили только за игровой гигант Activision Blizzard, который приобрела корпорация Microsoft за $68,7 млрд. Согласно договорённости, акционеры VMware получили премию...

На прошлой неделе мы писали о том, что компания VMware возвращает раздел Flings, где будут собраны полезные утилиты и инструменты, которые ранее были доступны администраторам и разработчикам через ресурс VMware Labs. Также совсем недавно VMware объявила о выпуске обновления ESXi Arm Edition 1.15, ну а сам продукт теперь называется ESXi for ARM.

О версии ESXi Arm Edition 1.14 мы писали вот тут. Напомним, что это решение представляет собой гипервизор для архитектуры ARM на базе кода ESXi. В будущем он найдет свое применение в таких решениях, как Project Monterey.

Давайте посмотрим, что нового появилось в VMware ESXi for ARM 1.15:

• Поддержка счетчиков производительности Virtual CPU Performance Counters
• Исправление виртуального UEFI для пакета Arm Architecture Compliance Suite
• Обновление драйвера EQOS:
  • Исправление перестановки байтов в MAC-адресе
  • Добавлена поддержка управления потоком данных IEEE 802.3x
• Поддержка устройств PCIe на Raspberry Pi Compute Module 4
• Отчет о версии и ревизии SoC, определенной Arm DEN0028 (как возвращается вызовом SMCCC_ARCH_SOC_ID SMC), через телеметрию.

Вот список платформ, на которых сейчас поддерживается работа ESXi for ARM, а также оборудования, где обширного тестирования не было, но гипервизор должен работать:

Скачать VMware ESXi for ARM можно по этой ссылке. Полный комплект документации доступен тут.

Многие из вас, вероятно, заметили, что пару месяцев назад ресурс VMware Labs стал перенаправлять на сайт VMware Developer, где размещены примеры различного кода и сценарии для автоматизации операций в виртуальной инфраструктуре. При этом полезные утилиты и виртуальные модули (VMware Flings) просто куда-то пропали.

Все это связано с большими процессами по реорганизации, которые сейчас происходят в компании VMware в связи с интеграцией в инфраструктуру Broadcom.

Но вот на днях появился ресурс, который содержит VMware Flings, где пользователи могут узнать о них информацию и загрузить их. Краткая ссылка для доступа к этим модулям теперь выглядит так: vmware.re/flings.

Выглядит это все, конечно, сейчас не очень. Утилиты размещены в каком-то странном порядке, например, первым идет гипервизор ESXi Arm Edition от 21 августа 2020, хотя он был обновлен в сентябре этого года. Но главное тут в том, что программа VMware Flings не будет свернута, а наоборот - подразделение VMware Cloud Foundation работает над возвращением полноценного раздела вспомогательных средств по управлению виртуальной инфраструктурой для сообщества администраторов и разработчиков.

Пока все это в процессе, вы можете использовать следующие ссылки для загрузки необходимых программ и утилит:

• ESXi-Arm - https://customerconnect.vmware.com/downloads/get-download?downloadGroup=ESXI-ARM (документация находится в верху списка загрузок)
• HCIBench - утилита переехала на Github - https://github.com/vmware-labs/hci-benchmark-appliance
• VMware Event Broker Appliance (VEBA) - напомним, что это open source продукт, и найти его можно здесь: https://github.com/vmware-samples/vcenter-event-broker-appliance, инструкции доступны тут.
• End Using Computing (EUC) Flings - большинство утилит из этой категории размещены здесь: https://techzone.vmware.com/utilities
• vSphere Diagnostic Tool (VDT) - эта полезная многим администраторам вещь доступна тут: https://kb.vmware.com/kb/83896 
• SDDC Import/Export - https://github.com/vmware-samples/sddc-import-export-for-vmware-cloud-on-aws
• Python Client for VMware Cloud on AWS (pyVMC) - https://github.com/vmware/python-client-for-vmware-cloud-on-aws
• VMware Cloud Size Companion CLI - https://github.com/vmware-samples/vmware-cloud-sizer-companion-cli
• Skyline CLI - https://developer.vmware.com/samples/8235/skyline-cli-v1.0.17
• Оставшиеся VMware Flings - пользователи Reddit скачали столько утилит, сколько смогли, и разместили их через Internet Archive по этой ссылке: https://archive.org/download/flings.vmware.com

Ожидаем, что в ближайшее время Broadcom не только вернет все как было, но и сделает намного лучше!

Как вы знаете, в мае этого года компания Broadcom объявила о приобретении компании VMware за 61 миллиард долларов, что стало новым этапом в развитии главного вендора в сфере виртуализации.

Недавно было объявлено о том, что Broadcom завершила процедуры по приобретению VMware и полной интеграции этого вендора в свое портфолио. В связи с этим пару дней назад Krish Prasad, занимающий позицию Senior Vice President and General Manager в подразделении VMware Cloud Foundation Division, рассказал о том, как изменится продуктовая линейка VMware. Главная новость - все станет намного проще, чего так долго ждали клиенты. А кое-что станет и в 2 раза дешевле!

Основные новые моменты тут следующие:

• Впредь будут доступны только два основных стандартных предложения: vSphere Foundation и VMware Cloud Foundation (VCF).
• Прекращение продажи бессрочных лицензий и продления подписки Support and Subscription (SnS).
• Лицензия Bring-your-own-subscription license (BYOL), которая обеспечивает переносимость онпремизных лицензий в гибридные облака, проверенные VMware и работающие на основе VMware Cloud Foundation.

Основной версией vSphere, используемой теперь, будет "vSphere Foundation".

Новый продукт VMware vSphere Foundation предлагает более упрощенную платформу для работы с корпоративными приложениями для клиентов среднего и небольшого размера. Это решение интегрирует vSphere с решениями для интеллектуального управления операциями, обеспечивая лучшую производительность, доступность и эффективность с большей видимостью и пониманием процессов.

Другими словами, начиная с декабря этого года, клиенты vSphere получают Aria Operations (ранее известный как vRealize Operations) и Aria Operations for Logs (ранее известный как vRealize Log Insight) вместе с vSphere (в который включены vCenter и Tanzu Kubernetes Grid).

Теперь издания VMware vSphere будут выглядеть так:

Существующие клиенты VCF или будущие большие клиенты vSphere Foundation будут переходить на новый VMware Cloud Foundation, который теперь можно считать полноценным решением для управления частным и гибридным облачным стеком.

VMware Cloud Foundation — это флагманское решение гибридного облака Enterprise-уровня, позволяющее клиентам безопасно, надежно и экономно управлять критически важными и современными приложениями. Чтобы больше клиентов могли воспользоваться этим решением, стоимость подписки была уменьшена вдвое, а также были добавлены более высокие уровни поддержки, включая расширенную поддержку для первоначальной активации решения и управления жизненным циклом.

Очень важно, если вы пропустили это в разделе выше: теперь vSphere Foundation будет включать только NSX for network virtualization (overlay), без возможностей микросегментации или распределенной брандмауэрной защиты (distributed firewalling, DFW). Другими словами, клиентам, которым нужны возможности DFW NSX (дополнение к сетевому экрану VMware), сначала нужна подписка на VCF, в которую входит NSX.

Обратите внимание, что в настоящее время все новые пакеты лицензий предоставляются в "disconnected" режиме (то есть без подключения к VMware Cloud).

Решения VMware Cloud on AWS, VMware Cloud on Azure и другие будут также включаться в инфраструктуру лицензирования VCF. Продукт VMware vSAN Enterprise теперь будет лицензироваться по числу TiB (аналог терабайтов) на заданное число ядер хостов ESXi.

Информацию об аддонах для VCF вы можете увидеть в первой картинке этой статьи - они точно такие же.

За более подробной информацией о новых изданиях платформы VMware vSphere вы можете обратиться к этой статье.

Вчера мы писали о том, как правильно обслуживать ISL-соединение растянутого кластера VMware vSAN. В этой статье был упомянут механизм vSAN Adaptive Quorum Control, который позволяет сохранять работоспособность растянутого кластера vSAN даже при последовательных отказах (например, сначала отказывает основная площадка, а затем и компонент Witness).

Видео ниже объясняет механику голосования, используемую vSAN в случае отказа одного из сайтов и последующего отказа Witness. Адаптивное управление кворумом присваивает больше голосов выжившему сайту, чтобы обеспечить обработку последующего отказа сайта свидетеля. Путем присвоения 3 голосов компонентам на выжившем сайте по-прежнему соблюдается большинство голосов. Даже если дополнительный хост ESXi на предпочтительном сайте потерян, всё равно есть достаточно голосов для достижения большинства, поэтому виртуальные машины продолжат функционировать.

Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...

Администраторы виртуальной инфраструктуры VMware vSphere время от времени сталкиваются с проблемой завершения зависших виртуальных машин. Если в клиенте vSphere Client сделать этого не удаются, приходится заходить в сервисную консоль ESXi или в командную строку PowerCLI/PowerShell и проводить там операции по завершению процесса этой ВМ. Сегодня мы расскажем о 5 способах, которыми это можно сделать.

1. С использованием PowerCLI

Stop-VM - это командлет, используемый для завершения работы виртуальной машины. На самом деле он используется для выключения ВМ, но добавление параметра kill приведет к завершению соответствующих процессов ВМ на ESXi, фактически уничтожая ее. Делается это так:

Stop-VM -kill <отображаемое имя ВМ> -Confirm:$false

2. С использованием esxcli

Esxcli - это интерфейс командной строки (CLI), который предоставляет доступ к ряду пространств имен, таких как vm, vsan, network и software, позволяя выполнять задачи, изменять настройки и так далее. Таким образом, если вам нужно завершить работу неотвечающей виртуальной машины с использованием esxcli, можно действовать следующим образом:

• Получить список виртуальных машин, размещенных на ESXi:

esxcli vm process list

Красным выделен идентификатор World ID виртуальной машины.

• Скопируйте значение World ID и выполните команду:

esxcli vm process kill --type=soft -w=796791

Команда не выдает никакой обратной связи, кроме случаев, когда она не сможет найти виртуальную машину или вы укажете неверный параметр.

Параметр type принимает три значения:

• Soft – позволяет процессу VMX завершиться корректно, аналогично команде kill -SIGTERM
• Hard – немедленно завершает процесс VMX, аналогично команде kill -9 или kill -SIGKILL
• Force – останавливает процесс VMX, когда не работают варианты Soft или Hard

3. С использованием утилиты vim-cmd

Vim-cmd - это еще одна утилита командной строки, очень похожая на esxcli, но с несколько иным синтаксисом. Также она может использоваться для управления ВМ и другими ресурсами. Соответственно, вот как используется vim-cmd для завершения работы ВМ:

1. Выведите все ВМ на текущем подключенном хосте ESXi и запишите vmid (первый столбец) неотвечающей ВМ:

vim-cmd vmsvc/getallvms

2. Получите состояние питания ВМ, используя ее vmid. Этот шаг необязателен, так как вы уже знаете, что с ВМ что-то не так:

vim-cmd vmsvc/power.getstate 36

3. Сначала попробуйте вариант power.shutdown:

vim-cmd vmsvc/power.shutdown 36

4. Если по какой-то причине ВМ не удается выключить, попробуйте использовать вместо этого power.off:

vim-cmd vmsvc/power.off 36

Следующий скриншот демонстрирует пример использования указанных выше команд для завершения работы ВМ.

4. С использованием esxtop

Esxtop - это отличная утилита, которая предоставляет информацию о том, как ESXi использует системные ресурсы. Она может использоваться для устранения неполадок, сбора статистики производительности и многого другого.

Вот как это делается:

Нажмите Shift+v, чтобы изменить представление на виртуальные машины:

Нажмите <f>, чтобы отобразить список полей, затем нажмите <c>. Это добавит столбец с идентификатором Leader World ID (LWID) в представление. Нажмите любую клавишу, чтобы вернуться в главное меню.

• Найдите зависшую виртуальную машину в столбце Name и запишите ее LWID.
• Нажмите k и введите значение LWID в строке запроса World to kill (WID). Нажмите Enter:

Чтобы быть полностью уверенным, подождите 30 секунд перед тем, как проверить, что виртуальная машина больше не отображается в списке. Если она все еще там, попробуйте снова. В случае неудачи, скорее всего, вам придется перезагрузить хост ESXi.

5. С помощью традиционной команды kill

Это самый грубый метод завершения работы виртуальной машины. Но он документирован на сайте VMware, хотя и немного по-другому. Виртуальная машина представляет собой серию процессов, выполняемых на ESXi. Используя команду ps ниже, можно вывести процессы, связанные, например, с виртуальной машиной под названием Web Server.

ps | grep "Web Server"

Если вы внимательно посмотрите, вы увидите, что значение во втором столбце одинаково для всех процессов. Это значение идентификатора VMX Cartel, которое, хотя и отличается от значения World ID, все же может быть использовано для завершения работы виртуальной машины следующим образом:

kill 797300

Если процессы продолжают работать, попробуйте kill -9 <идентификатор процесса>:

kill -9 797300

В начале года мы писали о документе "Performance Best Practices for VMware vSphere 8.0", в котором приведены основные рекомендации по обеспечению высокой производительности флагманской платформы виртуализации компании VMware. В середине этого года было сделано обновление этого руководства, которое было выпущено под названием "Performance Best Practices for VMware vSphere 8.0 Update 1".

В конце октября вышел очередной апдейт этого сверхполезного документа на 100 страницах - "Performance Best Practices for VMware vSphere 8.0 Update 2".

В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно vSphere 8 Update 2 и vSAN 8 Update 2.

Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

• Hardware for Use with VMware vSphere (страница 11)
• ESXi and Virtual Machines (страница 25)
• Guest Operating Systems (страница 55)
• Virtual Infrastructure Management (страница 67)

Предполагается, что читатель уже в достаточной степени осведомлен о методах управления виртуальной инфраструктурой и ее основных компонентах.

Скачать Performance Best Practices for VMware vSphere 8.0 Update 2 можно по этой ссылке.

Летом этого года вышла новая версия решения для виртуализации и доставки настольных ПК и приложений VMware Horizon 8 (2306). Напомним, что о прошлой версии Horizon 8 2303 мы писали в апреле этого года.

Сначала вот две ссылки на новые возможности агентов и клиентов, являющихся частью решения VMware Horizon 8:

• Новые возможности клиентов Horizon Clients в релизе Horizon 8 (2306)
• Новые возможности Horizon Agent в релизе VMware Horizon 8 (2306)

Сегодня мы поговорим о новой функциональности релиза 2306 (первые две цифры - это год, а оставшиеся - месяц релиза). Давайте посмотрим, что теперь нового в Horizon 8:

1. Гранулированные привилегии RBAC для клиентов, подключенных к облаку

В версиях Horizon 8 до 2306 для доступа к службам управления и мониторинга развертываний Horizon суперадминам требовалось активировать свою SaaS-подписку через Horizon Control Plane. Теперь, начиная с Horizon 2306, появились более детализированные привилегии на основе ролевого управления доступом (RBAC), которые позволяют суперадмину предоставлять гранулированные привилегии не-суперадминам, позволяя им активировать и управлять лицензиями, а также мониторить среду Horizon. Применяя специфические привилегии для админов, эта функция исключает необходимость ролей суперадмина для рутинных задач, при этом обеспечивая более строгую безопасность и гарантируя, что значительные изменения могут вносить только авторизованные сотрудники.

2. Блокировка подключения конечного пользователя, если нет проверки сертификата

Безопасность всегда на первом месте в разработке Horizon. С этой целью мы ввели новый механизм, который может обеспечивать проверку сертификата сервера. Как только настройка сконфигурирована, когда запрос конечного пользователя к десктопу или приложению доходит до connection server, запрос будет иметь уже настроенные параметры клиента, а не настройки, сконфигурированные администратором на сервере.

Управление соединениями определяется на основе конфигурации. Теперь есть три потенциальных действия — «Применить», «Предупредить» и «Игнорировать» — которые администраторы могут использовать для обеспечения более строгих политик проверки сертификатов:

• Применить (Enforce): Обязательная проверка сертификата. Если он недействителен, соединение разрывается.
• Предупредить (Warn): Пользователь получает предупреждение, ему разрешено подключиться, и событие регистрируется.
• Игнорировать (Ignore): Проверка сертификата выполняется, но создается только запись в журнале без уведомления пользователя.

Эта функция обеспечивает баланс между удобством использования и безопасностью, давая администраторам гибкость в определении строгости своего процесса аутентификации.

3. Фиксированный таймер для отмены учетных данных SSO, усиливающий безопасность

Клиенты могут установить фиксированный таймер для отмены учетных данных единого входа (SSO), чтобы гарантировать, что после определенного времени потребуется повторная аутентификация, что дополнительно усиливает безопасность. Администраторы могут устанавливать время сессии для конечных пользователей и гарантировать, что они проходят повторную аутентификацию при запуске новых сессий виртуальных рабочих столов или опубликованных приложений.

4. Настройка сопоставлений сертификатов из консоли

Для тех клиентов, которые используют аутентификацию на основе сертификата, такую как смарт-карты, обновление безопасности Microsoft (KB5014754) запретит слабые сопоставления сертификатов, такие как имя пользователя и электронная почта. Horizon 2306 позволяет настраивать сопоставления сертификатов из консоли Horizon. Эта функция предоставляет три варианта на выбор:

• SID, который считается самым надежным и рекомендуется
• Пользовательская альтернативная безопасная идентичность, такая как x509serialnumber, x509SKI.
• Устаревший вариант, для клиентов, которые не применяли обновление безопасности и продолжают использовать существующие смарт-карты.

5. Режим Instant Clone Smart Provisioning по умолчанию

Теперь Instant Clone Smart Provisioning по умолчанию использует режим Mode B (ВМ создается без родительской ВМ). Режим Mode B совместим со всеми рабочими процессами, такими как vTPM и vGPU. Режим Mode A (ВМ создается с родительской ВМ) выбирается только при использовании устройства vTPM на версии хоста ESXi ранее чем 7.0 обновление 3f. Вы все равно сможете изменить режим предоставления, но делать этого не рекомендуется.

6. Улучшение с авто-отладкой для мгновенных клонов

Автоматический режим отладки позволяет администраторам сохранять внутренние шаблоны ВМ для отладки в случае ошибок при развертывании. Ранее администраторам приходилось устанавливать параметр конфигурации для золотого образа в vCenter, чтобы включить этот режим. С этой функцией администраторы могут включать режим отладки из консоли, который применяется ко всем пулам мгновенных клонов (Instant Clones) в vCenter. Когда режим включен, внутренние шаблоны ВМ сохраняются в отдельной папке в vCenter, и эти ВМ автоматически удаляются, когда этот режим выключен. Рекомендуется включить настройку "Stop Provisioning on Error", чтобы развертывание останавливалось при первой ошибке, и эту конкретную ошибку можно было идентифицировать и отладить.

7. Постоянные диски для мгновенных клонов

Horizon 2306 вновь представляет persistent-диски для выделенных (dedicated) мгновенных клонов, предназначенные для клиентов, которые все еще их используют в Horizon 7. Эта новая функция предоставляет путь миграции для клиентов, которые не могут обновиться до Horizon 8 из-за постоянных дисков. Для получения дополнительной информации о миграции прочтите документ "Руководство по миграции для перехода с Horizon 7.X на Horizon 8".

8. Распределение сессий в архитектуре Cloud Pod

Чтобы помочь архитектуре Cloud Pod Architecture (CPA) равномерно распределять сессии пользователей по ресурсам в рамках глобального назначения, релиз 2306 вводит "Политику распределения нагрузки сессий" (Session Load Distribution Policy). Эта новая настройка позволяет администраторам выбирать методику подсчета сессий для установки политики распределения нагрузки сессий на основе глобального индивидуального назначения. С ее помощью CPA будет справедливо распределять входящие запросы сессий по ресурсам на основе подсчета сессий в отношении к емкости, обеспечивая более сбалансированное распределение по доступным ресурсам. Например, если глобальный entitlement имеет два пула рабочих столов, каждый с емкостью 100 рабочих столов, сессии будут равномерно распределяться по пулам для лучшей производительности рабочих столов и приложений.

Полную информацию обо всех нововведениях и улучшениях Horizon 8 релиз 2306 можно получить из Release Notes. Скачать компоненты решения можно по этой ссылке.

Компания VMware объявила о том, что ее флагманская платформа виртуализации vSphere 8 Update 2 и решение для создания отказоустойчивых кластеров vSAN 8 Update 2, анонсированные ранее в рамках конференции Explore 2023, стали доступны для скачивания в рамках фазы Initial Availability (напомним, что для vCenter Server это фаза General Availability).

Вот основная ссылка для загрузки всех компонентов VMware vSphere.

Для скачивания VMware vSAN 8 Update 2 используйте вот эту ссылку. Обратите также внимание на красное предупреждение вверху:

Если вы откроете VMware vSphere Client и посмотрите на список виртуальных дисков, прикрепленных к виртуальному модулю (Virtual Appliance) сервера vCenter, то вы увидите там аж 17 виртуальных дисков VMDK. Многие администраторы удивляются - а не многовато ли это?

Для VMware vSphere 7 список дисков и их назначение указаны в статье базы знаний KB 78515 (их там 16), ну а ниже мы расскажем о семнадцати VMDK для VMware vSphere 8:

Много? Много!